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Flow Bindings Initiated by Home Agents for Mobile IPv6 
Abstract 


There are scenarios in which the home agent needs to trigger flow 
binding operations towards the mobile node, such as moving a flow 
from one access network to another based on network resource 
availability. In order for the home agent to be able to initiate 
interactions for flow bindings with the mobile node, this document 
defines new signaling messages and sub-options for Mobile IPv6. Flow 
bindings initiated by a home agent are supported for mobile nodes 
enabled by both IPv4 and IPv6. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 
evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This is a contribution to the RFC Series, independently 
of any other RFC stream. The RFC Editor has chosen to publish this 
document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc7109. 
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Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 

(http: //trustee.ietf.org/license-info) in effect on the date of 
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Carefully, as they describe your rights and restrictions with respect 
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Introduction 


[RFC6089] allows a mobile node (MN) to bind a particular flow to a 
care-of address (CoA) without affecting other flows using the same 
home address. BU/BA (Binding Update / Binding Acknowledgement) 
messages are extended for the mobile node to add, delete, modify, 
move, refresh, and revoke flow bindings in a home agent (HA). The 
operations are always initiated by the mobile node. 


While the mobile node manipulates flow bindings by, e.g., the user 
interaction or the change of the attached link condition, these 
operations are also required for network-related reasons such as 
dynamic QoS control in the network, load balancing, or maintenance in 
mobility agent nodes. For the latter case, the mobile node is not 
very aware of the transport network condition away from it or of the 
policy and charging status controlled by the operator; thus, the 
network needs to request that the mobile node handle proper flow 
bindings. 


This document defines a new Mobility Header and messages in order for 
the home agent to request that the mobile node initiate flow bindings 
in a timely manner. Flow mobility is also supported for mobile nodes 
with an IPv4 home address and an IPv4 address of the home agent, as 
described in [RFC5555]. 


Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


The terminology in this document is based on the definitions in 
[RFC6275] and [RFC6089]. 


Use Cases 


.1. QoS Provisioning 


When the user launches a video chat application and starts sending 
voice and video to the other end, the network may need to provide 
different QoS treatments to these media based on the operator’s 
policy. In such a case, the network needs to request the user or 
mobile node to establish separate flows for voice and video. 
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3.2. Traffic Offload from Congested Network 


The 3G operator may want to move traffic flows from the 3G access 
network to another network (e.g., Wi-Fi network) due to instantaneous 
traffic increases in the 3G access network. Fine-grained traffic 
offload is desirable. For example, Voice over IP (VoIP) flows based 
on IP Multimedia Subsystems (IMS) must stay in the mobile core 
network while video-streaming flows provided by servers on the 
Internet could bypass the mobile core network via Wi-Fi access. 

Since the network knows more about its conditions and has access to 
the policy server, more timely and well-controlled traffic offloading 
is possible. The home agent sends an updated flow descriptor to be 
offloaded to the mobile node. 


3.3. Flow Movement or Deletion in an Emergency Situation 


In an emergency situation caused by a natural disaster, it is 
necessary to accept as many voice calls as possible for inquiries to 
confirm the safety status of family and friends, while non-critical 
services such as gaming would be considered lower priority. In order 
to save the 3G / Long Term Evolution (LTE) radio resources for 
emergency services, non-critical services may need to be moved to 
another access network or closed down. The home agent requests that 
the mobile node use Wi-Fi access for non-critical application flows 
or terminate them gracefully, e.g., by letting it notify the user of 
possible QoS degradation or ask him/her to finish the corresponding 
applications before taking any action. 


3.4. Service-Specific Data Cap 


The mobile operator offers a mobile broadband service with a flat 
rate subscription limited to 5 GB per month. Once the allotment is 
used up, the service is downgraded to 64 kbits/s. This limitation, 
however, is not applied to IMS-based services (e.g., Voice over LTE 
(VoLTE)), while video conversations over the Internet will be 
affected. The operator can indicate this to the user by sending 
modified flow descriptors as a proposal to adjust the communication 
data rate or change access for an ongoing session. 


4. Protocol Operation 


[RFC6089] makes use of BU/BA signaling to forward, i.e., register or 
discard, a flow binding in a home agent. Flow binding operations are 
always initiated from the mobile node. The basic principle of this 
specification is that the home agent prompts the mobile node to 
perform flow binding operations. For this purpose, a new Mobility 
Header and two new messages, that is, Flow Binding Indication (FBI) 
and Flow Binding Acknowledgement (FBA), are defined. An FBI is used 
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by the home agent to request flow binding operations to the mobile 
node, and an FBA is used for acknowledging an FBI. In order for the 
flow binding operation to be complete, a BU/BA exchange MUST be 
initiated by the mobile node after an FBI/FBA exchange. 


It is assumed that the home agent has already created binding cache 
entries for the mobile node before launching flow binding operations. 


Due to access-network change on the mobile-node side, some interfaces 
that used to be active may not be valid at the time of the flow 
binding operation by the home agent, in which case, even if the HA 
sends the FBI to the MN, the FBA will not return. After 
retransmitting the FBIs for MAX _FBI_RETRIES times and not receiving 
the FBA, the HA determines that the target interface is not 
available. 


If the mobile node does not support the FBI message, it responds with 
a Binding Error message with status set to 2 (unrecognized Mobility 
Header (MH) type value) as described in [RFC6275]. When the Binding 
Error message with status set to 2 is received in response to an FBI 
message, the home agent MUST NOT use an FBI message with that mobile 
node again. 


4.1. Adding Flow Bindings 


Adding the flow binding implies associating a particular flow with 
one of the care-of addresses on the mobile node. The care-of address 
concerned with the flow binding is present in the destination address 
of the packet or the alternate care-of address option. 

Alternatively, the care-of address may be indicated by the Target 
Care-of Address sub-option defined in Section 6.2.2. 


When adding a new flow binding, the home agent sends an FBI with a 
Flow Identification Mobility option to the mobile node. In Figure 1, 
which is shown as an example for this operation, the mobile node 
exchanges both voice and video over FID#1 (Flow Identifier #1). 

Based on the operator’s policy, the network determines if it needs to 
provide separate QoS for the video flow, and the home agent sends the 
FBI to the mobile node. The Flow Identification Mobility option 
defined in [RFC6089] includes the current FID and the Traffic 
Selector (TS) to specify the video flow. The Flow Binding Action 
sub-option MUST indicate the Add operation defined in Section 6.2.1. 
The mobile node returns the FBA to the home agent with the same 
options. The BU/BA exchange follows afterwards to perform the actual 
flow binding as defined in [RFC6088], and the video traffic is 
exchanged over FID#2. 
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+=---+ +=---+ 
| un | | HA | 
+=---+ +=---+ 
| FID#1 (voice+video) | 
|/ \| 
| \ / | 
| | 
| FBI (add, FID#1,TS[video]) | 
< A A an bl Yama padang gan Nan pasi ad a a a anang, 
FBA (FID#1,TS[video]) | 
| >| 
| BU (FID#2,TS[video]) | 
[o >| 
| BA (FID#2,TS[video]) | 
[o | 
| FID#1 (voice) | 
|< >| 
| FID#2 (video) | 
|< >| 


Figure 1: Example Call Flow for Adding a Flow Binding 
4.2. Deleting Flow Bindings 


When removing a flow binding, the home agent sends an FBI with a Flow 
Identification Mobility option in which the Flow Binding Action sub- 
option indicates the Delete operation. The Flow Identification 
Mobility option includes a unique FID for the mobile node to locate 
the flow binding and remove it. 


4.3. Modifying Flow Bindings 


When modifying a flow binding (e.g., changing QoS attributes of the 
flow as defined in [PMIP6-Q0S]) is needed, the home agent sends the 
mobile node an FBI message with the Flow Identification Mobility 
option. The option includes the FID to be modified. A Traffic 
Selector sub-option MAY come with the Flow Identification Mobility 
option and contain new attributes, e.g., the in Quality of Service 
option. 


4.4. Refreshing Flow Bindings 
A flow binding is refreshed by simply including the Flow 
Identification Mobility option with the Refresh Action field in the 


FBI message. The message should be sent before the expiration of the 
flow binding. The message updates existing bindings with new 
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information. Hence, all information previously sent in the last 
refreshing message need to be resent; otherwise, such information 
will be lost. 


4.5. Moving Flow Bindings 


The home agent can request to move a flow associated with one 
interface of the multi-interfaced mobile node to another by sending 
an FBI message to the mobile node. The Action field of the Flow 
Binding Action sub-option is set to Move, and the address of the 
target interface is also included in the Target Care-of Address sub- 
option. After the FBA is returned to the home agent, the flow 
mobility is performed by the mobile node. Figure 2 shows the 
movement of a flow label as FID from the interface with sCoA to that 
with tCoA, which is stored in the Binding Identity Mobility option. 


+----+ +----+ 
| MN | | HA | 
+----+ +----+ 
|<=sCoA | 
| |<=tCoA | 
| FBI (FID,tCoA) | 
< A A A A A Pang anaa Kn Kn 
TE FBA (FID, tCoA) 
| a a aka 4 
| | | 
| | BU (BID[tCoA], FID) | 
Tes Jai ai pen ke ee jang Ka Yani sai gi arai jasa a Bean je ey i Kami O yaaa ka > 
| | BA (BID[tCoA],FID) 
|| o | 
| 


Figure 2: Example Call Flow for Moving a Flow Binding 
4.6. Revoking Flow Bindings 


When the home agent or the network attached to it is overloaded, the 
home agent can revoke a flow binding registered by the mobile node. 
The home agent sends the mobile node an FBI message with a Flow 
Identification Mobility option in which the Flow Binding Action sub- 
option indicates the Revoke operation. When the MN receives the FBI 
message with the Revoke operation, it decides whether the flow should 
be removed (de-registration) or moved to another interface and 
returns the FBA with an appropriate status code. The mobile node 
SHOULD take an action by sending a new BU, for example, to deregister 
the flow. 
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The difference between revoking and deleting flow bindings 

(Section 4.2) is that the target flow may be revoked by the network 
with the procedures defined in [RFC5846] even if the mobile node does 
not take any action. 


5. Handling of the Flow Bindings List 


The flow bindings list defined in [RFC6089] needs to be updated as 
follows after each protocol operation defined above is performed: 


If an FBI contains a flow binding Add operation and if the 
corresponding FBA has a status code equal to zero, the home agent 
MUST add a new entry to the flow bindings list. The FID, Flow 
Descriptor, FID-PRI, and Action fields are taken from the Flow 
Identification Mobility option. The binding identifier (BID) is 
copied from the Binding Reference sub-option. The Active/Inactive 
Flag is set to Active. Note that if BID is not available, it may be 
replaced by Target Care-of Address. 


If an FBI contains a flow binding Delete operation and if the 
corresponding FBA has a status code equal to zero, the home agent 
MUST locate the list entry corresponding to this flow and then delete 
the entry. 


If the home agent sends a Binding Revocation Indication message with 
the Flow Identification Mobility option with the action field set to 
Revoke and if the corresponding Binding Revocation Acknowledgement 
message indicates acceptance, the home agent MUST locate the list 
entry corresponding to this flow and then delete the entry. 


If an FBI contains a flow binding Modify operation and if the 
corresponding FBA has a status code equal to zero, the home agent 
MUST delete the list entry corresponding to this flow and then add a 
new entry, setting the values as defined in the Flow Identification 
Mobility option. 


If an FBI contains a flow binding Refresh operation and if the 
corresponding FBA has a status code equal to zero, the home agent 
MUST locate the list entry corresponding to this flow and then set 
the Active/Inactive Flag to Active. 


If an FBI contains a flow binding Move operation and if the 
corresponding FBA has a status code equal to zero, the home agent 
MUST locate the list entry corresponding to this flow and then change 
the BID value to the care-of address in the Flow Identification 
Mobility option. 
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If an FBI contains a flow binding Revoke operation and if the 
corresponding FBA has a status code equal to zero, the home agent 
MUST locate the list entry corresponding to this flow and then delete 
the entry. 


Flow binding operations apply equally to IPv4 packets and IPv6 
packets as per Dual-Stack Mobile IPv6 [RFC5555]. In order to support 
the situation where there is a NAT/firewall between the mobile node 
and home agent, NAT detection and NAT keepalive mechanisms defined in 
[RFC5555] MUST be used. When the mobile node and home agent are in 
IPv6-only and IPv4-only networks respectively and NAT64 [RFC6146] 
resides in between, each node would behave as if the other node was 
in the same network domain. Even though this scenario is not fully 
described in [RFC5555], the initial mobility binding is always 
performed by the mobile node, and the binding cache is created in the 
home agent. The destination address of the FBI SHALL be the mobile 
node’s IPv4 care-of address in the binding cache entry. 


6. Flow Binding Messages and Options 


6.1. Mobility Header 


The messages described below follow the Mobility Header format 
specified in Section 6.1 of [RFC6275]. 


6.1.1. Flow Binding Indication 


Flow Binding Indication messages are used by the home agent to 
initiate flow binding operations to the mobile node. Flow Binding 
Indication messages use the MH Type value (21) for Flow Binding 
messages and a Flow Binding Type value of 1, and the format of the 
Message Data field in the Mobility Header is as follows: 


0 1 2 3 
Od 2. 3 A BS E + A VB E D 6.7 B29. Qs 62° 34. 5 67 gE 0 L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flow Binding Type = 1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sequence # | Trigger JA] Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
A Mobility options a 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: Flow Binding Indication Mobility Header Format 
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Sequence + 
A 16-bit unsigned integer used by the home agent to match a 
returned Flow Binding Acknowledgement with the Flow Binding 


Indication. It could be a random number. 

Trigger 
8-bit unsigned integer indicating the event that triggered the 
home agent to send the Flow Binding Indication message. The 


following Trigger values are currently defined: 
0 Reserved 
1 Unspecified 
2 Administrative Reason 
3 Possible Out-of-Sync BCE State 
250-255 Reserved for Testing Purposes Only 
All other values are unassigned. 
Acknowledge (A) 
The Acknowledge (A) bit is set by the home agent to request that a 


Flow Binding Acknowledgement be returned upon receipt of the Flow 
Binding Indication. 


Reserved 
These fields are unused. They MUST be initialized to zero by the 
sender and MUST be ignored by the receiver. 


Mobility options 
Variable-length field of such length that the complete Mobility 
Header is an integer multiple of 8 octets long. Flow 
Identification Mobility options are included in this field. 


6.1.2. Flow Binding Acknowledgement 


The Flow Binding Acknowledgement is used to acknowledge receipt of a 
Flow Binding Indication. The mobile node sends an FBA message to 
acknowledge the reception of an FBI to add, delete, modify, refresh, 
move, or revoke a flow binding. On receiving messages with Flow 
Identification Mobility option(s), the mobile node should copy each 
Flow Identification Mobility option to the Acknowledgement message. 
The Flow Binding Acknowledgement has the MH Type value (21) for Flow 
Binding messages and a Flow Binding Type value of 2. When this value 
is indicated in the MH Type field, the format of the Message Data 
field in the Mobility Header is as follows: 
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0 1 2 3 
012345678901 23456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flow Binding Type = 2 | 
dd + anaha nana nana nanda, naka, sanad $ $ q — $ + q ++ q +4 anaha nanah nanah nanah, nanah nana nana nanah nanah Nana anaha Kana a 
| Sequence # | Status | Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ q d+ q +4 +++ +++ +++ +++ 
6 Mobility options A 
Pod + + dd hd dd $ $ q — $ + q dd q +4 +++ +++ +++ +++ 
Figure 4: Flow Binding Acknowledgement Mobility Header Format 


Sequence + 
The sequence number in the Flow Binding Acknowledgement is copied 
from the Sequence Number field in the Flow Binding Indication. 


Status 
8-bit unsigned integer indicating the result of processing the 
Flow Binding Indication message by the receiving mobile node. 
Values less than 128 in the Status field indicate that the Flow 
Binding Indication was processed successfully by the receiving 
node. Values greater than or equal to 128 indicate that the Flow 
Binding Indication was rejected by the receiving node. The 
following status values are currently defined: 


0 Success 
128 Binding (target CoA) Does NOT Exist 
129 Action NOT Authorized 
All other values are unassigned. 
Mobility options 
Variable-length field of such length that the complete Mobility 
Header is an integer multiple of 8 octets long. This field 
contains zero or more TLV-encoded mobility options. Flow 
Identification Mobility options are included in this field. 
6.1.3. Flow Binding Revocation Extensions 
This specification enables Binding Revocation Indication and Binding 
Revocation Acknowledgement messages to carry Flow Identification 


Mobility options as defined in [RFC6089] with the extensions defined 
in this document. 
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6.2. New Options 


This document defines new Flow Identification sub-options that are 
included in the Flow Identification Mobility option specified in 
[RFC6089]. 


6.2.1. Flow Binding Action Sub-Option 


This section defines a new sub-option for flow binding actions, which 
MUST be included in the Flow Identification Mobility option when it 
is sent from the home agent to the mobile node via the FBI message. 
The format of this sub-option is shown in Figure 5. 


0 1 2 3 

O S DO PAS <9 00° 223A E 8 0 NGA 34 00067 06:90, 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sub-opt Type | Sub-opt Length | Reserved | Action | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 5: Flow Binding Action Sub-Option 


Sub-opt Type 
4 


Sub-opt Length 
Length of the sub-option in octets, excluding the Sub-opt Type and 
Sub-opt Length fields. 


Action 
This is a 8-bit field that describes the required processing for 
the option. It can be assigned one of the following new values: 


11 Add a flow binding 

12 Delete a flow binding 

13 Modify a flow binding 

14 Refresh a flow binding 
15 Move a flow binding 

16 Revoke a flow binding 


All other values are unassigned. 
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6.2.2. Target Care-of Address Sub-Option 


This section introduces the Target Care-of Address sub-option, which 
may be included in the Flow Identification Mobility option. This 
sub-option is used to indicate to the mobile node that a flow binding 
is to be moved from one interface to another. 


0 1 2 3 
0.12 34 OF Bk Ds Oo 2 Bi 68 GOO) LA 2 BAe Be 0. PB <9. 0: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Sub-opt Type | Sub-opt Length | Reserved 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Target Care-of Address 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 6: Target Care-of Address Sub-Option 


Sub-opt Type 
5 


Sub-opt Length 
Length of the sub-option in octets, excluding the Sub-opt Type and 
Sub-opt Length fields. 


Reserved 
This field is unused. It MUST be initialized to zero by the 
sender and MUST be ignored by the receiver. 


Target Care-of Address 
The address of an interface that the flow is moved to. This 
address could be an IPv4 or IPv6 address. This sub-option MUST be 
included when the action taken is "15 Move a flow binding". 


7. Security Considerations 


Security issues for this document follow those of [RFC6088], 
[RFC6089], and [RFC5846]. This specification allows the home agent 
to manipulate only the binding of a flow(s) that is currently 
registered with it, which is the same principle described in 
[RFC5846]. No additional security issue specific to this document is 
identified. 
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8. 


Protocol Constants 


Maximum FBI retries (MAX_FBI_RETRIES) 


This variable specifies the maximum number of times the HA MAY 
retransmit a Flow Binding Indication message when the FBA is not 
returned within the time period specified by MAX_FBA_TIMEOUT. The 
default value for this parameter is 3. 


Maximum FBA timeout (MAX_FBA_ TIMEOUT) 


This variable specifies the maximum time in seconds the HA MUST 
wait before retransmitting another FBI message. The default for 
this parameter is 3 seconds. 


IANA Considerations 


IANA has taken the actions described below. 


Action-1 


This specification defines a new Mobility Header Type, "Flow 
Binding Message". This Mobility Header message is described in 
Section 6.1, and the type value for this messages is 21, which has 
been assigned in the "Mobility Header Types — for the MH Type 
field in the Mobility Header" registry. 


Action-2 


This specification defines "Flow Binding Type". IANA has created 
a new sub-registry within the "Mobile IPv6 parameters" registry. 
Flow Binding Type is described in Sections 6.1.1 and 6.1.2, which 
reserve the following values: 


+------- $ +-------------- + 
| Value | Description | Reference | 
+------- $ == +-------------- + 
| 0 | Unassigned | 

+------- $ +-------------- + 
| 1 | Flow Binding Indication | [RFC7109] | 
+------- +------------------------------ +-------------- + 
| 2 | Flow Binding Acknowledgement | [RFC7109] | 
+------- +------------------------------ +-------------- + 
| 3-255 | Unassigned | 

FO O +-------------- + 


Future assignments in the "Flow Binding Type" registry are to be 
made through RFC Required [RFC5226]. 


Yokota, et al. Experimental [Page 14] 


REC 7109 HA-Initiated Flow Binding for MIPv6 February 2014 


Action-3 
This specification defines "Flow Binding Indication Triggers". 
IANA has created a new sub-registry within the "Mobile IPv6 
parameters" registry. The trigger values are described in 
Section 6.1.1, which reserves the following values: 


Ho +------------------------------------ do E A E + 
| Value | Description | Reference | 
Ho == SS SS SS SS +-------------- + 
| 0 | Reserved | [RFC7109] | 
Ho dep 2855235558 He===55====32= + 
| 1 | Unspecified | [RFC7109] | 
Ho ti a a +-------------- + 
| 2 | Administrative Reason | [RFC7109] 
Ho q aka KA 2 = SSS e SS H=>==5=== === + 
| 3 | Possible Out-of-Sync BCE State | [RFC7109] | 
SIRO A A A A a +-------------- + 
| 4-249 | Unassigned | 
Ho +------------------------------------ $ + 
| 250-255 | Reserved for Testing Purposes Only | [RFC7109] | 
e P SS a aik Sa E E +-------------- + 
Future assignments in the "Flow Binding Indication Triggers" 
registry are to be made through RFC Required [RFC5226]. 
Action-4 
This specification defines "Flow Binding Acknowledgement Status 
Codes". IANA has created a new sub-registry within the "Mobile 
IPv6 parameters" registry. The status codes are described in 
Section 6.1.2, which reserves the following values: 
Ho eo +-------------- + 
| Value | Description | Reference | 
Ho +—------------------------------------- do a + 
| 0 | Success | [RFC7109] | 
fermei SS sá A See eee SS SSeS Pos Sess + 
| 1-127 | Unassigned | | 
Posa PHS SSeS aa Se Sse Sessa aa aaa PS 2223 + 
| 128 | Binding (target CoA) Does NOT Exist | [RFC7109] | 
pann tiegi HERAS ah a aa aa e Se eases so a aan + 
| 129 | Action NOT Authorized | [RFC7109] 
Ho === 233 = 19 SS > SS SS SS +-------------- + 
| 130-255 | Unassigned | 
Ho +------------------------------------- do E + 


Future assignments in the "Flow Binding Acknowledgement Status 
Codes" are to be made through RFC Required [RFC5226]. 
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Action-5 
This specification defines two new Flow Identification sub- 
options: the "Flow Binding Action" sub-option and "Target Care-of 
Address" sub-option. These sub-options are described in Sections 
6.2.1 and 6.2.2, and the sub-option values are 4 and 5, 
respectively, as assigned in the "Flow Identification Sub-options" 
registry. 


Action-6 
This specification defines "Flow Binding Action Values". IANA has 
created a new sub-registry within the "Mobile IPv6 parameters" 
registry. The action values are described in Section 6.2.1, which 
reserves the following values: 


+-------- +---------------------- = -- = == - == +-------------- + 
| Value | Description | Reference | 
+-------- +---------------------------- = +-------------- + 
| 0-10 | Unassigned | | 
+-------- 4+---------------------------- === +-------------- + 
| 11 | Add a flow binding | [RFC7109] | 
+-------- 4+---------------------------- === +-------------- + 
| 12 | Delete a flow binding | [RFC7109] | 
+-------- +---------------------- = - = - === +-------------- + 
| 13 | Modify a flow binding | [RFC7109] | 
+-------- $ O O - = - === +-------------- + 
[> 14 | Refresh a flow binding | [REC7109] | 
+-------- PO = - === +-------------- + 
| PS-u Move a flow binding | [RFC7109] | 
+-------- +--------------------- === == === +-------------- + 
| 16 | Revoke a flow binding | [RFC7109] 
+-------- $ == +-------------- + 
| 17-255 | Unassigned | 

+-------- +---------------------- === -- == +-------------- + 


Future assignments in the "Flow Binding Action Values" registry 
are to be made through RFC Required [RFC5226]. 
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